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1. Introduction 


This document discusses the history of funding for Internet research, 
expresses concern about the current state of such funding, and 
outlines several specific areas that the IAB believes merit 
additional research. Current funding levels for Internet research 
are not generally adequate, and several important research areas are 
significantly underfunded. This situation needs to be rectified for 
the Internet to continue its evolution and development. 


1.1. Document Organization 


The first part of the document is a high-level discussion of the 
history of funding for Internet research to provide some historical 
context to this document. The early funding of Internet research was 
largely from the U.S. government, followed by a period in the second 
half of the 1990s of commercial funding and of funding from several 
governments. However, the commercial funding for Internet research 
has been reduced due to the recent economic downturn. 
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The second part of the document provides an incomplete set of open 
Internet research topics. These are only examples, intended to 
illustrate the breadth of open research topics. This second section 
supports the general thesis that ongoing research is needed to 
further the evolution of the Internet infrastructure. This includes 
research on the medium-time-scale evolution of the Internet 
infrastructure as well as research on longer-time-scale grand 
challenges. This also includes many research issues that are already 
being actively investigated in the Internet research community. 


Areas that are discussed in this section include the following: 


naming, routing, security, network management, and transport. Issues 
that require more research also include more general architectural 
issues such as layering and communication between layers. In 


addition, general topics discussed in this section include modeling, 
measurement, simulation, test-—beds, etc. We are focusing on topics 
that are related to the IETF and IRTF (Internet Research Task Force) 
agendas. (For example, Grid issues are not discussed in this 
document because they are addressed through the Global Grid Forum and 
other Grid-specific organizations, not in the IETF.) 


Where possible, the examples in this document point to separate 
documents on these issues, and only give a high-level summary of the 
issues raised in those documents. 


1.2. IAB Concerns 


In the aftermath of September 11 2001, there seems to be a renewed 
interest by governments in funding research for Internet-related 
security issues. From [Jackson02]: "It is generally agreed that the 
security and reliability of the basic protocols underlying the 
Internet have not received enough attention because no one has a 
proprietary interest in them". 


That quote brings out a key issue in funding for Internet research, 
which is that because no single organization (e.g., no single 
government, software company, equipment vendor, or network operator) 
has a sense of ownership of the global Internet infrastructure, 
research on the general issues of the Internet infrastructure are 
often not adequately funded. In our current challenging economic 
climate, it is not surprising that commercial funding sources are 
more likely to fund that research that leads to a direct competitive 
advantage. 


The principal thesis of this document is that if commercial funding 
is the main source of funding for future Internet research, the 
future of the Internet infrastructure could be in trouble. In 
addition to issues about which projects are funded, the funding 
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YAP 


source can also affect the content of the research, for example, 
towards or against the development of open standards, or taking 
varying degrees of care about the effect of the developed protocols 
on the other traffic on the Internet. 


At the same time, many significant research contributions in 
networking have come from commercial funding. However, for most of 
the topics in this document, relying solely on commercially-funded 
research would not be adequate. Much of today’s commercial funding 
is focused on technology transition, taking results from non- 
commercial research and putting them into shipping commercial 
products. We have not tried to delve into each of the research 
issues below to discuss, for each issue, what are the potentials and 
limitations of commercial funding for research in that area. 


On a more practical note, if there was no commercial funding for 
Internet research, then few research projects would be taken to 
completion with implementations, deployment, and follow-up 
evaluation. 


While it is theoretically possible for there to be too much funding 
for Internet research, that is far from the current problem. There 
is also much that could be done within the network research community 
to make Internet research more focused and productive, but that would 
belong in a separate document. 


3. Contributions to this Document 
A number of people have directly contributed text for this document, 
even though, following current conventions, the official RFC author 
list includes only the key editors of the document. The 
Acknowledgements section at the end of the document thanks other 
people who contributed to this document in some form. 

History of Internet Research and Research Funding 
1. Prior to 1980 


Most of the early research into packet-switched networks was 
sponsored by the U.S. Defense Advanced Research Projects Agency 
(DARPA) [CSTB99]. This includes the initial design, implementation, 
and deployment of the ARPAnet connecting several universities and 
other DARPA contractors. The ARPAnet originally came online in the 
late 1960s. It grew in size during the 1970s, still chiefly with 
DARPA funding, and demonstrated the utility of packet-switched 
networking. 
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DARPA funding for Internet design started in 1973, just four years 
after the initial ARPAnet deployment. The support for Internet 
design was one result of prior DARPA funding for packet radio and 
packet satellite research. The existence of multiple networks 
(ARPAnet, packet radio, and packet satellite) drove the need for 
internetworking research. The Internet arose in large measure as a 
consequence of DARPA research funding for these three networks -- and 
arise only incidentally from the commercially-funded work at Xerox 
PARC on Ethernet. 


2.2. 1980s and early 1990s 


The ARPAnet converted to the Internet Protocol (IP) on January 1, 
1983, approximately 20 years before this document was written. 
Throughout the 1980s, the U.S. Government continued strong research 
and development funding for Internet technology. DARPA continued to 
be the key funding source, but was supplemented by other DoD (U.S. 
Department of Defense) funding (e.g., via the Defense Data Network 
(DDN) program of the Defense Communication Agency (DCA)) and other 
U.S. Government funding (e.g., U.S. Department of Energy (DoE) 
funding for research networks at DoE national laboratories, (U.S.) 
National Science Foundation (NSF) funding for academic institutions). 
This funding included basic research, applied research (including 
freely distributable prototypes), the purchase of IP-capable 
products, and operating support for the IP-based government networks 
such as ARPAnet, ESnet, MILnet, the NASA Science Internet, and 
NSFnet. 


During the 1980s, the U.S. DoD desired to leave the business of 
providing operational network services to academic institutions, so 
funding for most academic activities moved over to the NSF during the 
decade. NSF’s initial work included sponsorship of CSnet in 1981. 

By 1986, NSF was also sponsoring various research projects into 
networking (e.g., Mills’ work on Fuzzballs). In the late 1980s, NSF 
created the NSFnet backbone and sponsored the creation of several NSF 
regional networks (e.g., SURAnet) and interconnections with several 
international research networks. NSF also funded gigabit networking 
research, through the Corporation for National Research Initiatives 
(CNRI), starting in the late 1980s. It is important to note that the 
NSF sponsorship was focused on achieving core NSF goals, such as 
connecting scientists at leading universities to NSF supercomputing 
centers. The needs of high-performance remote access to 
supercomputers drove the overall NSFnet performance. As a side 
effect, this meant that students and faculty at those universities 
enjoyed a relatively high-performance Internet environment. As those 
students graduated, they drove both commercial use of the Internet 
and the nascent residential market. It is no accident that this was 
the environment from which the world wide web emerged. 
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Most research funding outside the U.S. during the 1980s and early 
1990s was focused on the ISO OSI networking project or on then-new 
forms of network media (e.g., wireless, broadband access). The 
European Union was a significant source of research funding for the 
networking community in Europe during this period. Some of the best 
early work in gigabit networking was undertaken in the UK and Sweden. 


2.3. Mid-1990s to 2003 


Starting in the middle 1990s, U.S. Government funding for Internet 
research and development was significantly reduced. The premise for 
this was that the growing Internet industry would pay for whatever 
research and development that was needed. Some funding for Internet 
research and development has continued in this period from European 
and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). 
Reseaux IP Europeens [RIPE] is an example of market-funded networking 
research in Europe during this period. 


Experience during this period has been that commercial firms have 
often focused on donating equipment to academic institutions and 
promoting somewhat vocationally-focused educational projects. Many 
of the commercially-funded research and development projects appear 
to have been selected because they appeared likely to give the 
funding source a specific short-term economic advantage over its 
competitors. Higher risk, more innovative research proposals 
generally have not been funded by industry. A common view in Silicon 
Valley has been that established commercial firms are not very good 
at transitioning cutting edge research into products, but were 
instead good at buying small startup firms who had successfully 
transitioned such cutting edge research into products. 
Unfortunately, small startup companies are generally unable 
financially to fund any research themselves. 


2.4. Current Status 


The result of reduced U.S. Government funding and profit-—focused, 
low-risk, short-term industry funding has been a decline in higher- 
risk but more innovative research activities. Industry has also been 
less interested in research to evolve the overall Internet 
architecture, because such work does not translate into a competitive 
advantage for the firm funding such work. 


The IAB believes that it would be helpful for governments and other 
non-commercial sponsors to increase their funding of both basic 
research and applied research relating to the Internet, and to 
sustain these funding levels going forward. 
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3. Open Internet Research Topics 


This section primarily discusses some specific topics that the IAB 
believes merit additional research. Research, of course, includes 
not just devising a theory, algorithm, or mechanism to accomplish a 
goal, but also evaluating the general efficacy of the approach and 
then the benefits vs. the costs of deploying that algorithm or 
mechanism. Important cautionary notes about this discussion are 
given in the next sub-section. This particular set of topics is not 
intended to be comprehensive, but instead is intended to demonstrate 
the breadth of open Internet research questions. 


Other discussions of problems of the Internet that merit further 
research include the following: 
[CIPBO2,Claffy03a,Floyd,NSF03a,NSFO03b]. 


3.1. Scope and Limitations 


This document is NOT intended as a guide for public funding agencies 
as to exactly which projects or proposals should or should not be 
funded. 


In particular, this document is NOT intended to be a comprehensive 
list of *all* of the research questions that are important to further 
the evolution of the Internet; that would be a daunting task, and 
would presuppose a wider and more intensive effort than we have 
undertaken in this document. 


Similarly, this document is not intended to list the research 
questions that are judged to be only of peripheral importance, or to 
survey the current (global; governmental, commercial, and academic) 
avenues for funding for Internet research, or to make specific 
recommendations about which areas need additional funding. The 
purpose of the document is to persuade the reader that ongoing 
research is needed towards the continued evolution of the Internet 
infrastructure; the purpose is not to make binding pronouncements 
about which specific areas are and are not worthy of future funding. 


For some research clearly relevant to the future evolution of the 
Internet, there are grand controversies between competing proposals 
or competing schools of thought; it is not the purpose of this 
document to take positions in these controversies, or to take 
positions on the nature of the solutions for areas needing further 
research. 
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That all carefully noted, the remainder of this section discusses a 
broad set of research areas, noting a subset of particular topics of 
interest in each of those research areas. Again, this list is NOT 
comprehensive, but rather is intended to suggest that a broad range 
of ongoing research is needed, and to propose some candidate topics. 


3.1.1. Terminology 


Several places in this document refer to ’network operators’. By 
that term, we intend to include anyone or any organization that 
operates an IP-based network; we are not using that term in the 
narrow meaning of commercial network service providers. 


3.2. Naming 


The Internet currently has several different namespaces, including IP 
addresses, sockets (specified by the IP address, upper-layer 
protocol, and upper-layer port number), Autonomous System (AS) 
number, and the Fully-Qualified Domain Name (FQDN). Many of the 
Internet’s namespaces are supported by the widely deployed Domain 
Name System [RFC-3467] or by various Internet applications [RFC-2407, 
Section 4.6.2.1] 


3.2.1. Domain Name System (DNS) 


The DNS system, while it works well given its current constraints, 
has several stress points. 


The current DNS system relies on UDP for transport, rather than SCTP 
or TCP. Given the very large number of clients using a typical DNS 
server, it is desirable to minimize the state on the DNS server side 
of the connection. UDP does this well, so it is a reasonable choice, 
though this has other implications, for example a reliance on UDP 
fragmentation. With IPv6, intermediate fragmentation is not allowed 
and Path MTU Discovery is mandated. However, the amount of state 
required to deploy Path MTU Discovery for IPv6 on a DNS server might 
be a significant practical problem. 


One implication of this is that research into alternative transport 
protocols, designed more for DNS-like applications where there are 
very many clients using each server, might be useful. Of particular 
interest would be transport protocols with little burden for the DNS 
server, even if that increased the burden somewhat for the DNS 
client. 


Additional study of DNS caching, both currently available caching 


techniques and also of potential new caching techniques, might be 
helpful in finding ways to reduce the offered load for a typical DNS 
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server. In particular, examination of DNS caching through typical 
commercial firewalls might be interesting if it lead to alternative 
firewall implementations that were less of an obstacle to DNS 
caching. 


The community lacks a widely-agreed-upon set of metrics for measuring 


DNS server performance. It would be helpful if people would 
seriously consider what characteristics of the DNS system should be 
measured. 


Some in the community would advocate replacing the current DNS system 
with something better. Past attempts to devise a better approach 
have not yielded results that persuaded the community to change. 
Proposed work in this area could be very useful, but might require 
careful scrutiny to avoid falling into historic design pitfalls. 


With regards to DNS security, major technical concerns include 
finding practical methods for signing very large DNS zones (e.g., and 
tools to make it easier to manage secure DNS infrastructure. 


Most users are unable to distinguish a DNS-related failure froma 
more general network failure. Hence, maintaining the integrity and 
availability of the Domain Name System is very important for the 
future health of the Internet. 


3.2.2. New Namespaces 


Additionally, the Namespace Research Group (NSRG) of the Internet 
Research Task Force (IRTF) studied adding one or more additional 
namespaces to the Internet Architecture [LD2002]. Many members of 
the IRTF NSRG believe that there would be significant architectural 
benefit to adding one or more additional namespaces to the Internet 
Architecture. Because smooth consensus on that question or on the 
properties of a new namespace was not obtained, the IRTF NSRG did not 
make a formal recommendation to the IETF community regarding 
namespaces. The IAB believes that this is an open research question 
worth examining further. 


Finally, we believe that future research into the evolution of 
Internet-based distributed computing might well benefit from studying 
adding additional namespaces as part of a new approach to distributed 
computing. 


3.3. Routing 
The currently deployed unicast routing system works reasonably well 


for most users. However, the current unicast routing architecture is 
suboptimal in several areas, including the following: end-to-end 
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convergence times in global-scale catenets (a system of networks 
interconnected via gateways); the ability of the existing inter- 
domain path-vector algorithm to scale well beyond 200K prefixes; the 
ability of both intra-domain and inter-domain routing to use multiple 
metrics and multiple kinds of metrics concurrently; and the ability 
of IPv4 and IPv6 to support widespread site multi-homing without 
undue adverse impact on the inter-domain routing system. Integrating 
policy into routing is also a general concern, both for intra-domain 
and inter-domain routing. In many cases, routing policy is directly 
tied to economic issues for the network operators, so applied 
research into routing ideally would consider economic considerations 
as well as technical considerations. 


This is an issue for which the commercial interest is clear, but that 
seems unlikely to be solved through commercial funding for research, 
in the absence of a consortium of some type. 


3.3.1. Inter-domain Routing 


The current operational inter-domain routing system has between 
150,000 and 200,000 routing prefixes in the default-free zone (DFZ) 
[RFC-3221]. ASIC technology obviates concerns about the ability to 
forward packets at very high speeds. ASIC technology also obviates 
concerns about the time required to perform longest-prefix-match 
computations. However, some senior members of the Internet routing 
community have concerns that the end-to-end convergence properties of 
the global Internet might hit fundamental algorithmic limitations 
(i.e., not hardware limitations) when the DFZ is somewhere between 
200,000 and 300,000 prefixes. Research into whether this concern is 
well-founded in scientific terms seems very timely. 


Separately from the above concern, recent work has shown that there 
can be significant BGP convergence issues today. At present, it 
appears that the currently observed convergence issues relate to how 
BGP has been configured by network operators, rather than being any 
sort of fundamental algorithmic limitation [MGVK02]. This 
convergence time issue makes the duration of the apparent network 
outage much longer than it should be. Additional applied research 
into which aspects of a BGP configuration have the strongest impact 
on convergence times would help mitigate the currently observed 
operational issues. 


Also, inter-domain routing currently requires significant human 
engineering of specific inter-AS paths to ensure that reasonably 
optimal paths are used by actual traffic. Ideally, the inter-domain 
routing system would automatically cause reasonably optimal paths to 
be chosen. Recent work indicates that improved BGP policy mechanisms 


Atkinson & Floyd Informational [Page 10] 


RFC 3869 Research Funding Recommendations August 2004 


might help ensure that reasonably optimal paths are normally used for 
inter-domain IP traffic. [SMA03] Continued applied research in this 
area might lead to substantially better technical approaches. 


The current approach to site multi-homing has the highly undesirable 
side-effect of significantly increasing the growth rate of prefix 
entries in the DFZ (by impairing the deployment of prefix 
aggregation). Research is needed into new routing architectures that 
can support large-scale site multi-homing without the undesirable 
impacts on inter-domain routing of the current multi-homing 
technique. 


The original application for BGP was in inter-domain routing, 
primarily within service provider networks but also with some use by 
multi-homed sites. However, some are now trying to use BGP in other 
contexts, for example highly mobile environments, where it is less 
obviously well suited. Research into inter-domain routing and/or 
intra-domain policy routing might lead to other approaches for any 
emerging environments where the current BGP approach is not the 
optimal one. 


3.3.2. Routing Integrity 


Recently there has been increased awareness of the longstanding issue 
of deploying strong authentication into the Internet inter-domain 
routing system. Currently deployed mechanisms (e.g., BGP TCP MD5 
[RFC-2385], OSPF MD5, RIP MD5 [RFC-2082]) provide cryptographic 
authentication of routing protocol messages, but no authentication of 
the actual routing data. Recent proposals (e.g., S-BGP [KLMS2000]) 
for improving this in inter-domain routing appear difficult to deploy 
across the Internet, in part because of their reliance on a single 
trust hierarchy (e.g., a single PKI). Similar proposals (e.g., OSPF 
with Digital Signatures, [RFC-2154]) for intra-domain routing are 
argued to be computationally infeasible to deploy in a large network. 


A recurring challenge with any form of inter-domain routing 
authentication is that there is no single completely accurate source 
of truth about which organizations have the authority to advertise 
which address blocks. Alternative approaches to authentication of 
data in the routing system need to be developed. In particular, the 
ability to perform partial authentication of routing data would 
facilitate incremental deployment of routing authentication 
mechanisms. Also, the ability to use non-hierarchical trust models 
(e.g., the web of trust used in the PGP application) might facilitate 
incremental deployment and might resolve existing concerns about 
centralized administration of the routing system, hence it merits 
additional study and consideration. 
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3.3.3. Routing Algorithms 


The current Internet routing system relies primarily on two 
algorithms. Link-state routing uses the Dijkstra algorithm 
[Dijkstra59]. Distance-Vector routing (e.g., RIP) and Path-Vector 
routing (e.g., BGP) use the Bellman-Ford algorithm [Bellman1957, 
FF1962]. Additional ongoing basic research into graph theory as 
applied to routing is worthwhile and might yield algorithms that 
would enable a new routing architecture or otherwise provide 
improvements to the routing system. 


Currently deployed multicast routing relies on the Deering RPF 
algorithm [Deering1988]. Ongoing research into alternative multicast 
routing algorithms and protocols might help alleviate current 
concerns with the scalability of multicast routing. 


The deployed Internet routing system assumes that the shortest path 
is always the best path. This is provably false, however it is a 
reasonable compromise given the routing protocols currently 
available. The Internet lacks deployable approaches for policy-based 
routing or routing with alternative metrics (i.e., some metric other 
than the number of hops to the destination). Examples of alternative 
policies include: the path with lowest monetary cost; the path with 
the lowest probability of packet loss; the path with minimized 
jitter; and the path with minimized latency. Policy metrics also 
need to take business relationships into account. Historic work on 
QoS-based routing has tended to be unsuccessful in part because it 
did not adequately consider economic and commercial considerations of 
the routing system and in part because of inadequate consideration of 
security implications. 


Transitioning from the current inter-domain routing system to any new 
inter-domain routing system is unlikely to be a trivial exercise. So 
any proposal for a new routing system needs to carefully consider and 
document deployment strategies, transition mechanisms, and other 
operational considerations. Because of the cross-domain 
interoperability aspect of inter-domain routing, smooth transitions 
from one inter-domain routing system are likely to be difficult to 
accomplish. Separately, the inter-domain routing system lacks strong 
market forces that would encourage migration to better technical 
approaches. Hence, it appears unlikely that the commercial sector 
will be the source of a significantly improved inter-domain routing 
system. 
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3.3.4. Mobile and Ad-Hoc Routing 


While some of the earliest DARPA-sponsored networking research 
involved packet radio networks, mobile routing [IM1993] and mobile 
ad-hoc routing [RFC-2501] are relatively recent arrivals in the 
Internet, and are not yet widely deployed. The current approaches 
are not the last word in either of those arenas. We believe that 
additional research into routing support for mobile hosts and mobile 
networks is needed. Additional research for ad-hoc mobile hosts and 
mobile networks is also worthwhile. Ideally, mobile routing and 
mobile ad-hoc routing capabilities should be native inherent 
capabilities of the Internet routing architecture. This probably 
will require a significant evolution from the existing Internet 
routing architecture. (NB: The term "mobility" as used here is not 
limited to mobile telephones, but instead is very broadly defined, 
including laptops that people carry, cars/trains/aircraft, and so 
forth.) 


Included in this topic are a wide variety of issues. The more 
distributed and dynamic nature of partially or completely self- 
organizing routing systems (including the associated end nodes) 
creates unique security challenges (especially relating to 
Authorization, Authentication, and Accounting, and relating to key 
management). Scalability of wireless networks can be difficult to 
measure or to achieve. Enforced hierarchy is one approach, but can 
be very limiting. Alternative, less constraining approaches to 
wireless scalability are desired. Because wireless link-layer 
protocols usually have some knowledge of current link characteristics 
such as link quality, sublayer congestion conditions, or transient 
channel behavior, it is desirable to find ways to let network-layer 
routing use such data. This raises architectural questions of what 
the proper layering should be, which functions should be in which 
layer, and also practical considerations of how and when such 
information sharing should occur in real implementations. 


3.4. Security 


The Internet has a reputation for not having sufficient security. In 
fact, the Internet has a number of security mechanisms standardized, 
some of which are widely deployed. However, there are a number of 
open research questions relating to Internet security. In 
particular, security mechanisms need to be incrementally deployable 
and easy to use. "[Security] technology must be easy to use, or it 
will not be configured correctly. If mis-configured, security will 
be lost, but things will ‘work’" [Schiller03]. 
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3.4.1. Formal Methods 


There is an ongoing need for funding of basic research relating to 
Internet security, including funding of formal methods research that 
relates to security algorithms, protocols, and systems. 


For example, it would be beneficial to have more formal study of 
non-hierarchical trust models (e.g., PGP’s Web-of-Trust model). Use 
of a hierarchical trust model can create significant limitations in 
how one might approach securing components of the Internet, for 
example the inter-domain routing system. So research to develop new 
trust models suited for the Internet or on the applicability of 
existing non-hierarchical trust models to existing Internet problems 
would be worthwhile. 


While there has been some work on the application of formal methods 
to cryptographic algorithms and cryptographic protocols, existing 
techniques for formal evaluation of algorithms and protocols lack 
sufficient automation. This lack of automation means that many 
protocols aren’t formally evaluated in a timely manner. This is 
problematic for the Internet because formal evaluation has often 
uncovered serious anomalies in cryptographic protocols. The creation 
of automated tools for applying formal methods to cryptographic 
algorithms and/or protocols would be very helpful. 


3.4.2. Key Management 


A recurring challenge to the Internet community is how to design, 
implement, and deploy key management appropriate to the myriad of 
security contexts existing in the global Internet. Most current work 
in unicast key management has focused on hierarchical trust models, 
because much of the existing work has been driven by corporate or 
military "top-down" operating models. 


The paucity of key management methods applicable to non-hierarchical 
trust models (see above) is a significant constraint on the 
approaches that might be taken to secure components of the Internet. 


Research focused on removing those constraints by developing 
practical key management methods applicable to non-hierarchical trust 
models would be very helpful. 


Topics worthy of additional research include key management 
techniques, such as non-hierarchical key management architectures 
(e.g., to support non-hierarchical trust models; see above), that are 
useful by ad-hoc groups in mobile networks and/or distributed 
computing. 
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Although some progress has been made in recent years, scalable 
multicast key management is far from being a solved problem. 

Existing approaches to scalable multicast key management add 
significant constraints on the problem scope in order to come up with 
a deployable technical solution. Having a more general approach to 
scalable multicast key management (i.e., one having broader 
applicability and fewer constraints) would enhance the Internet’s 
capabilities. 


In many cases, attribute negotiation is an important capability of a 
key management protocol. Experience with the Internet Key Exchange 
(IKE) to date has been that it is unduly complex. Much of IKE’s 
complexity derives from its very general attribute negotiation 
capabilities. A new key management approach that supported 
Significant attribute negotiation without creating challenging levels 
of deployment and operations complexity would be helpful. 


3.4.3. Cryptography 


There is an ongoing need to continue the open-world research funding 
into both cryptography and cryptanalysis. Most governments focus 
their cryptographic research in the military-sector. While this is 
understandable, those efforts often have limited (or no) publications 
in the open literature. Since the Internet engineering community 
must work from the open literature, it is important that open-world 
research continues in the future. 


3.4.4. Security for Distributed Computing 


MIT’s Project Athena was an important and broadly successful research 
project into distributed computing. Project Athena developed the 
Kerberos [RFC-1510] security system, which has significant deployment 
today in campus environments. However, inter-realm Kerberos is 
neither as widely deployed nor perceived as widely successful as 
single-realm Kerberos. The need for scalable inter-domain user 
authentication is increasingly acute as ad-hoc computing and mobile 
computing become more widely deployed. Thus, work on scalable 
mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain 
authentication would be very helpful. 


3.4.5. Deployment Considerations in Security 


Lots of work has been done on theoretically perfect security that is 
impossible to deploy. Unfortunately, the S-BGP proposal is an 
example of a good research product that has significant unresolved 
deployment challenges. It is far from obvious how one could widely 
deploy S-BGP without previously deploying a large-scale inter-domain 
public-key infrastructure and also centralizing route advertisement 
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policy enforcement in the Routing Information Registries or some 
Similar body. Historically, public-key infrastructures have been 
either very difficult or impossible to deploy at large scale. 
Security mechanisms that need additional infrastructure have not been 
deployed well. We desperately need security that is general, easy to 
install, and easy to manage. 


3.4.6. Denial of Service Protection 


Historically, the Internet community has mostly ignored pure Denial 
of Service (DoS) attacks. This was appropriate at one time since 
such attacks were rare and are hard to defend against. However, one 
of the recent trends in adversarial software (e.g., viruses, worms) 
has been the incorporation of features that turn the infected host 
into a "zombie". Such zombies can be remotely controlled to mount a 
distributed denial of service attack on some victim machine. In many 
cases, the authorized operators of systems are not aware that some or 
all of their systems have become zombies. It appears that the 
presence of non-trivial numbers of zombies in the global Internet is 
now endemic, which makes distributed denial of service attacks a much 
larger concern. So Internet threat models need to assume the 
presence of such zombies in significant numbers. This makes the 
design of protocols resilient in the presence of distributed denial 
of service attacks very important to the health of the Internet. 

Some work has been done on this front [Savage00], [MBFIPS0O1], but 
more is needed. 


3.5. Network Management 


The Internet had early success in network device monitoring with the 
Simple Network Management Protocol (SNMP) and its associated 
Management Information Base (MIB). There has been comparatively less 
success in managing networks, in contrast to the monitoring of 
individual devices. Furthermore, there are a number of operator 
requirements not well supported by the current Internet management 
framework. It is desirable to enhance the current Internet network 
management architecture to more fully support operational needs. 


Unfortunately, network management research has historically been very 
underfunded. Operators have complained that existing solutions are 
inadequate. Research is needed to find better solutions. 


3.5.1. Managing Networks, Not Devices 


At present there are few or no good tools for managing a whole 
network instead of isolated devices. For example, the lack of 
appropriate network management tools has been cited as one of the 
major barriers to the widespread deployment of IP multicast [Diot00, 
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SM03]. Current network management protocols, such as the Simple 
Network Management Protocol (SNMP), are fine for reading status of 
well-defined objects from individual boxes. Managing networks 
instead of isolated devices requires the ability to view the network 
as a large distributed system. Research is needed on scalable 
distributed data aggregation mechanisms, scalable distributed event 
correlation mechanisms, and distributed and dependable control 
mechanisms. 


Applied research into methods of managing sets of networked devices 
seems worthwhile. Ideally, such a management approach would support 
distributed management, rather than being strictly centralized. 


3.5.2. Enhanced Monitoring Capabilities 


SNMP does not always scale well to monitoring large numbers of 
objects in many devices in different parts of the network. An 
alternative approach worth exploring is how to provide scalable and 
distributed monitoring, not on individual devices, but instead on 
groups of devices and the network-as-a-whole. This requires scalable 
techniques for data aggregation and event correlation of network 
status data originating from numerous locations in the network. 


3.5.3. Customer Network Management 


An open issue related to network management is helping users and 
others to identify and resolve problems in the network. If a user 
can’t access a web page, it would be useful if the user could find 
out, easily, without having to run ping and traceroute, whether the 
problem was that the web server was down, that the network was 
partitioned due to a link failure, that there was heavy congestion 
along the path, that the DNS name couldn’t be resolved, that the 
firewall prohibited the access, or that some other specific event 
occurred. 


3.5.4. Autonomous Network Management 


More research is needed to improve the degree of automation achieved 
by network management systems and to localize management. Autonomous 
network management might involve the application of control theory, 
artificial intelligence or expert system technologies to network 
management problems. 


3.6. Quality of Service 
There has been an intensive body of research and development work on 


adding QoS to the Internet architecture for more than ten years now 
[RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], yet we still 
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don’t have end-to-end QoS in the Internet [RFC-2990, RFC-3387]. The 
IETF is good at defining individual QoS mechanisms, but poor at work 
on deployable QoS architectures. Thus, while Differentiated Services 
(DiffServ) mechanisms have been standardized as per-hop behaviors, 
there is still much to be learned about the deployment of that or 
other QoS mechanisms for end-to-end QoS. In addition to work on 
purely technical issues, this includes close attention to the 
economic models and deployment strategies that would enable an 
increased deployment of QoS in the network. 


In many cases, deployment of QoS mechanisms would significantly 
increase operational security risks [RFC-2990], so any new research 
on QoS mechanisms or architectures ought to specifically discuss the 
potential security issues associated with the new proposal(s) and how 
to mitigate those security issues. 


In some cases, the demand for QoS mechanisms has been diminished by 
the development of more resilient voice/video coding techniques that 
are better suited for the best-effort Internet than the older coding 
techniques that were originally designed for circuit-—switched 
networks. 


One of the factors that has blunted the demand for QoS has been the 
transition of the Internet infrastructure from heavy congestion in 
the early 1990s, to overprovisioning in backbones and in many 
international links now. Thus, research in QoS mechanisms also has 
to include some careful attention to the relative costs and benefits 
of QoS in different places in the network. Applied research into QoS 
should include explicit consideration of economic issues of deploying 
and operating a QoS-enabled IP network [Clark02]. 


3.6.1. Inter-Domain QoS Architecture 


Typically, a router in the deployed inter-domain Internet provides 
best-effort forwarding of IP packets, without regard for whether the 
source or destination of the packet is a direct customer of the 
operator of the router. This property is a significant contributor 
to the current scalability of the global Internet and contributes to 
the difficulty of deploying inter-domain Quality of Service (QoS) 
mechanisms. 


Deploying existing Quality-of-Service (QoS) mechanisms, for example 
Differentiated Services or Integrated Services, across an inter- 
domain boundary creates a significant and easily exploited denial-of- 
service vulnerability for any network that provides inter-domain QoS 
support. This has caused network operators to refrain from 
supporting inter-domain QoS. The Internet would benefit from 
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additional research into alternative approaches to QoS, particularly 
into approaches that do not create such vulnerabilities and can be 
deployed end-to-end [RFC-2990]. 


Also, current business models are not consistent with inter-domain 
QoS, in large part because it is impractical or impossible to 
authenticate the identity of the sender of would-be preferred traffic 
while still forwarding traffic at line-rate. Absent such an ability, 
it is unclear how a network operator could bill or otherwise recover 
costs associated with providing that preferred service. So any new 
work on inter-domain QoS mechanisms and architectures needs to 
carefully consider the economic and security implications of such 
proposals. 


3.6.2. New Queuing Disciplines 


The overall Quality-of-Service for traffic is in part determined by 
the scheduling and queue management mechanisms at the routers. While 
there are a number of existing mechanisms (e.g., RED) that work well, 
it is possible that improved active queuing strategies might be 
devised. Mechanisms that lowered the implementation cost in IP 
routers might help increase deployment of active queue management, 
for example. 


3.7. Congestion Control. 


TCP’s congestion avoidance and control mechanisms, from 1988 
[Jacobson88], have been a key factor in maintaining the stability of 
the Internet, and are used by the bulk of the Internet’s traffic. 
However, the congestion control mechanisms of the Internet need to be 
expanded and modified to meet a wide range of new requirements, from 
new applications such as streaming media and multicast to new 
environments such as wireless networks or very high bandwidth paths, 
and new requirements for minimizing queueing delay. While there are 
significant bodies of work in several of these issues, considerably 
more needs to be done. 


We would note that research on TCP congestion control is also not yet 
"done", with much still to be accomplished in high-speed TCP, or in 
adding robust performance over paths with significant reordering, 
intermittent connectivity, non-congestive packet loss, and the like. 


Several of these issues bring up difficult fundamental questions 
about the potential costs and benefits of increased communication 
between layers. Would it help transport to receive hints or other 
information from routing, from link layers, or from other transport- 
level connections? If so, what would be the cost to robust operation 
across diverse environments? 
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For congestion control mechanisms in routers, active queue management 
and Explicit Congestion Notification are generally not yet deployed, 
and there are a range of proposals, in various states of maturity, in 
this area. At the same time, there is a great deal that we still do 
not understand about the interactions of queue management mechanisms 
with other factors in the network. Router-based congestion control 
mechanisms are also needed for detecting and responding to aggregate 
congestion such as in Distributed Denial of Service attacks and flash 
crowds. 


As more applications have the need to transfer very large files over 
high delay-bandwidth-product paths, the stresses on current 
congestion control mechanisms raise the question of whether we need 
more fine-grained feedback from routers. This includes the challenge 
of allowing connections to avoid the delays of slow-start, and to 
rapidly make use of newly-available bandwidth. On a more general 
level, we don’t understand the potential and limitations for best- 
effort traffic over high delay-bandwidth-product paths, given the 
current feedback from routers, or the range of possibilities for more 
explicit feedback from routers. 


There is also a need for long-term research in congestion control 
that is separate from specific functional requirements like the ones 
listed above. We know very little about congestion control dynamics 
or traffic dynamics of a large, complex network like the global 
Internet, with its heterogeneous and changing traffic mixes, link- 
level technologies, network protocols and router mechanisms, patterns 
of congestion, pricing models, and the like. Expanding our knowledge 
in this area seems likely to require a rich mix of measurement, 
analysis, simulations, and experimentation. 


3.8. Studying the Evolution of the Internet Infrastructure 


The evolution of the Internet infrastructure has been frustratingly 
slow and difficult, with long stories about the difficulties in 
adding IPv6, QoS, multicast, and other functionality to the Internet. 
We need a more scientific understanding of the evolutionary 
potentials and evolutionary difficulties of the Internet 
infrastructure. 


This evolutionary potential is affected not only by the technical 
issues of the layered IP architecture, but by other factors as well. 
These factors include the changes in the environment over time (e.g., 
the recent overprovisioning of backbones, the deployment of 
firewalls), and the role of the standardization process. Economic 
and public policy factors are also critical, including the central 
fact of the Internet as a decentralized system, with key players 
being not only individuals, but also ISPs, companies, and entire 
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industries. Deployment issues are also key factors in the evolution 
of the Internet, including the continual chicken-and-egg problem of 
having enough customers to merit rolling out a service whose utility 
depends on the size of the customer base in the first place. 


Overlay networks might serve as a transition technology for some new 
functionality, with an initial deployment in overlay networks, and 
with the new functionality moving later into the core if it seems 
warranted. 


There are also increased obstacles to the evolution of the Internet 
in the form of increased complexity [WD02], unanticipated feature 
interactions [Kruse00], interactions between layers [CWWS92], 
interventions by middleboxes [RFC-3424], and the like. Because 
increasing complexity appears inevitable, research is needed to 
understand architectural mechanisms that can accommodate increased 
complexity without decreasing robustness of performance in unknown 
environments, and without closing off future possibilities for 
evolution. More concretely, research is needed on how to evolve the 
Internet will still maintaining its core strengths, such as the 
current degree of global addressability of hosts, end-to-end 
transparency of packet forwarding, and good performance for best- 
effort traffic. 


3.9. Middleboxes 


Research is needed to address the challenges posed by the wide range 
of middleboxes [RFC-3234]. This includes issues of security, 
control, data integrity, and on the general impact of middleboxes on 
the architecture. 


In many ways middleboxes are a direct outgrowth of commercial 
interests, but there is a need to look beyond the near-term needs for 
the technology, to research its broader implications and to explore 
ways to improve how middleboxes are integrated into the architecture. 


3.10. Internet Measurement 


A recurring challenge is measuring the Internet; there have been many 
discussions about the need for measurement studies as an integral 
part of Internet research [Claffy03]. In this discussion, we define 
measurement quite broadly. For example, there are numerous 
challenges in measuring performance along any substantial Internet 
path, particularly when the path crosses administrative domain 
boundaries. There are also challenges in measuring 
protocol/application usage on any high-speed Internet link. Many of 
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the problems discussed above would benefit from increased frequency 
of measurement as well as improved quality of measurement on the 
deployed Internet. 


A key issue in network measurement is that most commercial Internet 
Service Providers consider the particular characteristics of their 
production IP network(s) to be trade secrets. Ways need to be found 
for cooperative measurement studies, e.g., to allow legitimate non- 
commercial researchers to be able to measure relevant network 
parameters while also protecting the privacy rights of the measured 
ISPs. 


Absent measured data, there is possibly an over-reliance on network 
simulations in some parts of the Internet research community and 
probably insufficient validation that existing network simulation 
models are reasonably good representations of the deployed Internet 
(or of some plausible future Internet) [FK02]. 


Without solid measurement of the current Internet behavior, it is 
very difficult to know what otherwise unknown operational problems 
exist that require attention, and it is equally difficult to fully 
understand the impact of changes (past or future) upon the Internet’s 
actual behavioral characteristics. 


3.11. Applications 


Research is needed on a wide range of issues related to Internet 
applications. 


Taking email as one example application, research is needed on 
understanding the spam problem, and on investigating tools and 
techniques to mitigate the effects of spam, including tools and 
techniques that aid the implementation of legal and other non- 
technical anti-spam measures [ASRG]. "Spam" is a generic term for a 
range of significantly different types of unwanted bulk email, with 
many types of senders, content and traffic-generating techniques. As 
one part of controlling spam, we need to develop a much better 
understanding of its many, different characteristics and their 
interactions with each other. 


3.12. Meeting the Needs of the Future 


As network size, link bandwidth, CPU capacity, and the number of 
users all increase, research will be needed to ensure that the 
Internet of the future scales to meet these increasing demands. We 
have discussed some of these scaling issues in specific sections 
above. 
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However, for all of the research questions discussed in this 
document, the goal of the research must be not only to meet the 
challenges already experienced today, but also to meet the challenges 
that can be expected to emerge in the future. 


3.13. Freely Distributable Prototypes 


U.S.’s DARPA has historically funded development of freely 
distributable implementations of various Internet technologies (e.g., 
TCP/IPv4, RSVP, IPv6, and IP security) in a variety of operating 
systems (e.g., 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). Experience has 
shown that a good way to speed deployment of a new technology is to 
provide an unencumbered, freely-distributable prototype that can be 
incorporated into commercial products as well as non-commercial 
prototypes. Japan’s WIDE Project has also funded some such work, 
primarily focused on IPv6 implementation for 4.4 BSD and Linux. 
[WIDE] We believe that applied research projects in networking will 
have an increased probability of success if the research project 
teams make their resulting software implementations freely available 
for both commercial and non-commercial uses. Examples of successes 
here include the DARPA funding of TCP/IPv4 integration into the 4.x 
BSD operating system [MBKQ96], DARPA/USN funding of ESP/AH design and 
integration into 4.4 BSD [Atk96], as well as separate DARPA/USN and 
WIDE funding of freely distributable IPv6 prototypes [Atk96, WIDE]. 


4. Conclusions 


This document has summarized the history of research funding for the 
Internet and highlighted examples of open research questions. The 
TAB believes that more research is required to further the evolution 
of the Internet infrastructure, and that consistent, sufficient non- 
commercial funding is needed to enable such research. 


In case there is any confusion, in this document we are not 
suggesting any direct or indirect role for the IAB, the IETF, or the 
IRTF in handling any funding for Internet research. 
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